Software development

ABSTRACT

A method of developing software capable of performing a task is disclosed. The task comprises at least one task step required to perform the task. The task step has a resultant effect. The method comprises: recording a use case comprising one or more scenarios, the or each scenario comprising one or more further steps; recording said scenario or one of said scenarios as a main success scenario such that the resultant effect of said main success scenario is the same as the resultant effect of said task step. Also disclose is the re-use of use cases which have been stripped of context-specific information. Such information may be included in a reference to the re-used use case.

This invention relates to development of software, and more particularlyto methods, software and tools to facilitate such development.

Software development projects in many cases involve as much manpowerresources as architectural or civil engineering projects, however, theprogress and the results are not as easy to visualise. Thus softwaredevelopment involving more than one person has always been difficult tocontrol effectively, and for this reason it has been the consensus forsome time that a defined process is required. Development without aprocess gives rise to the following problems:

-   -   over-reliance on having the right people.    -   Difficulties in co-ordination and communication between people.    -   Inaccurate planning.    -   Lack of code/module re-use.    -   Lack of predictability of the software.

Processes have been developed in recent years, however, for variousreasons they have not been widely used. The following are some of theproblems:

-   -   The process is not suitable for Object-Oriented (O) development.    -   There is a perception that implementation of a process involves        too much overhead and additional developer time.    -   There is a perception that projects below a certain size are too        small for implementation of a process.    -   The available processes do not strike a good balance between the        traditional “waterfall” approach in which every stage must be        completely finished before proceeding to the next stage, and the        other extreme of constantly iterating in apparently endless        cycles.

It is an aim of the present invention at least partially to alleviatethese problems.

When viewed from a first aspect, the present invention provides a methodof developing software capable of performing a task, said taskcomprising at least one task step required to perform said task, thestep having a resultant effect, wherein the method comprises: recordinga use case comprising one or more scenarios, the or each scenariocomprising one or more further steps; and recording said scenario or oneof said scenarios as a main success scenario such that the resultanteffect of said main success scenario is the same as the resultant effectof said step.

Thus it will be seen by those skilled in the art that in accordance withthe present invention a software development method is provided wherebya task step to be carried out by the software may be broken down bymeans of a main success scenario which has further steps which add up tothe same net effect as the overall task step. In other words detail maybe added to each step in an organised and straightforward way. Thisprocess may, and typically will, be continued for several layers.

In other words, for some or all of the ‘further’ steps in the mainsuccess scenario, there may be recorded use cases which themselves havemain success scenarios and a number of yet further steps. Detail maycontinue to be added until such time as there is sufficient detail totranslate into code. Thus the same use case structure may be applied atall levels of abstraction throughout the software development lifecycle.

Such an organised structure is beneficial in the development of softwareas it ensures openness during the development process and, for example,allows easy evaluation of the extent of development which has beenachieved at any given point in the software development life cycle.

The relationship between a task step and its more detailed use case isknown as a refinement relationship and in preferred embodiments, themethod comprises recording a refinement relationship which links thetask step to the use case. By recording the relationship, it is clearhow further detail has been added. Preferably the method comprisesrecording a justification for said refinement relationship, saidjustification demonstrating how the resultant effect of the main successscenario within the more detailed use case equals the resultant effectof the task step.

Use cases in accordance with the invention may be allowed only a mainsuccess scenario. Preferably however the use case may also have one ormore alternative scenarios. The alternative scenario(s) may not have aresultant effect which is the same as that of the task step which theuse case refines.

In some preferred embodiments, the use case has a requiredpost-condition. That is, a condition which must be satisfied once theuse case has been executed. A post-condition may be visually representedas applying to the use case as a whole, but preferably is represented ina meta model as applying to the main success scenario—since analternative scenario may not be able to meet the post-condition.

In some preferred embodiments, the use case has a requiredpre-condition. That is, a condition that must be satisfied before theuse case is executed. A pre-condition may be applied to the use case asa whole since it does not depend on whether the main success scenario oran alternative scenario is followed.

It will be appreciated by those skilled in the art that the methods setout hereinabove in accordance with the invention may benefit any singlesoftware development project or part of a project by giving enhancedstructure and visibility to the project. This is true even if all of thetask steps and use cases are built from scratch. Preferably, however,the method comprises recording a reference to one or more use casesstored elsewhere—i.e. that have been previously built. This is extremelybeneficial in allowing use cases to be reused. Not only does this savethe time that would otherwise have been taken to build the use case, butalso the time associated with checking, testing, validating etc. The usecase referred to may previously have been built in an earlier project orin a different part of the same project.

It will be appreciated that uses cases at any level of detail may bereused. Where a higher level use case is reused, the further stepscomprised in its main success or alternative scenarios will be reused.These further steps may themselves be refined into lower level use caseswhich might, although need not necessarily, also be reused. In otherwords, if a user reuses a use case he/she may utilise the refinementswithin it, or equally may define new refinements, subject to any pre- orpost-conditions. It will be appreciated that this is an advantageconferred by the fact that the resultant effect of the task step and themain success scenario of the refining use case are ensured to be thesame.

The benefits of reusing use cases may be achieved by reusing the sameuse case in the same context in which it was built. In thesecircumstances, the use case could be specific to that context. It ispreferred however that use cases do not contain any context-specificinformation. For example any context-specific information required forthe use case could be recorded separately, e.g. in a separate referenceobject rather than in the use case itself.

The term context, when applied to use cases, should be understood asreferring to the ability to specify additional attributes of that usecase which are specific to the particular environment in which the usecase is used, without affecting the pre- and/or post-conditions (whereprovided for) of the use case itself. For example the context of a usecase may be the project in which the use case is used. In this case thecontext specific information could be attributes such as the priority ofthat use case in that project, or the delivery increment in which it isdue to be delivered. Alternatively the context of a use case may be asubset of a whole project.

Effectively this means that the structure of the use case, i.e. thecollection of steps and optional pre- and/or post-conditions, may bemaintained while allowing the use case to show context-specificattributes. By separating a Use Case into two types: a pure use case anda use case reference, and relating these two types by means of areference relationship, reuse of use cases across different contexts,e.g. different projects, may be achieved.

This apparently simple feature in fact greatly enhances the power andvalue of reusability in accordance with the invention. By stripping usecases of their context, the opportunity for reusing them becomessignificantly greater and the avoidance of repeated effort may beoptimised. For example, the task step “Make Payment” may be used in abusiness model to pay for received goods, issue a refund or award aprize. Regardless of the business context that the use case is used in,its resultant effect is still the same: money passes from payer topayee.

Such an arrangement is considered to be novel and inventive in it's ownright and thus when viewed from a further aspect the invention providesa method of developing software capable of performing a task, said taskcomprising at least one main step required to perform said task, themain step having a resultant effect, wherein the method comprisesrecording a reference to a use case comprising one or more further stepssuch that said further steps have a resultant effect which is the sameas the resultant effect of the main step; wherein said use case isstored elsewhere and has no context-specific information, therebyallowing re-use of said use case.

At least some use cases may be stored in the part of the project wherethey are first built. This is most applicable in the circumstances ofreuse within a given software development project. Additionally oralternatively, use cases may be stored in a repository. This is mostapplicable in the circumstances of reuse between separate softwaredevelopment projects. Indeed as well as storing use cases which arebuilt in the context of a particular project, such an approach allowsuse cases to be proactively built outside of any particular project foremployment in subsequent projects.

The use cases in a repository of the type set out above may simply bestored there once they have been built. Preferably however therepository comprises a separate section for storing use cases which havebeen ‘qualified’—i.e. those which have been tested, checked for lack ofcontext-specific information, or had context-specific informationremoved.

In the following, the term “collaboration” may be taken to beinterchangeable with the term “use case”. Furthermore the term “action”may be taken to be interchangeable with the term “step” or “task step”.No inference is to be drawn by use of the former term rather than thelatter or vice versa.

When viewed from a yet further aspect the present invention provides asoftware development method comprising the steps of defining processworkflows for use cases and roles, wherein:

-   -   the use cases are represented as actions, each having an        associated effect defining a required post-condition for the        action; and    -   use cases are stored in an asset repository according to a meta        model which allows retrieval of use cases for re-use.

In one embodiment, at least some use cases are represented in the metamodel as a collaboration linked to actions, in which each action and thecollaboration is linked to an associated effect, and the collaborationis a more detailed representation of the actions. In one embodiment,each effect states both a pre-condition and a post-condition.

In one embodiment, a collaboration is linked to an action by arefinement relationship. In one embodiment, the refinement relationshipstates what stage of the project life-cycle the project is at.

In one embodiment, there is a justification associated with eachrefinement relationship, stating how the action is realised by therefining collaboration.

In one embodiment, the method uses a predicate justification stating howeach clause in an action's pre-condition expression is realised by aclause in a collaboration pre-condition.

In one embodiment, the method uses a diagrammatic justification defininghow entities of the action are realised in the refining collaboration.

In one embodiment, a model for a project is generated from the metamodel by re-use of parts of the meta model in the asset repository.

In one embodiment, the model is generated by use of an include patternfor inclusion of actions and collaborations of the meta model.

In one embodiment, the model comprises only a reference to acollaboration or action, the actual action or collaboration being storedin the meta model.

In one embodiment, the model is extended by inheriting behaviour ofreference types and refinement of included collaborations.

In one embodiment, the meta model models a business context for abusiness process.

In one embodiment, the method uses a proactive content group thatproactively creates re-useable artefacts.

In one embodiment, the method comprises the step of mapping requirementsto software components for technical mapping.

In one embodiment, the meta model represents use cases at differentlevels of abstraction and in different contexts.

In one embodiment, the meta model comprises refinement relationshipslinking views of processes at different levels of detail to providetraceability.

In one embodiment, a refinement relationship links an action to acollaboration, in which a collaboration is a more detailedrepresentation of an action.

In one embodiment, the meta model represents use cases independent ofcontext, and allows a context to be applied without change to a base usecase.

According to another aspect, the invention provides a softwaredevelopment system comprising means for defining process workflows foruse cases and roles in a method as defined above.

When viewed from further aspects the present invention providesrespectively a software development tool, a computer program product andcomplementary client and sever software for carrying out the methods setout hereinabove.

Certain preferred embodiments of the present invention will now bedescribed, by way of example only, with reference to the accompanyingdrawings in which:

FIG. 1 is a diagram showing refinement using a meta model in accordancewith an embodiment of the present invention;

FIG. 2 is a diagram showing refinement in the meta model;

FIG. 3 is a diagram showing Include and Exclude patterns using a metamodel;

FIG. 4 is a diagram showing Include and Extend patterns in the metamodel;

FIG. 5 is a diagram showing the Include pattern;

FIG. 6 is a diagram showing an Extend pattern;

FIG. 7 is a diagram showing action re-use in the meta model;

FIG. 8 is a diagram showing action re-use using the meta model;

FIG. 9 is a diagram illustrating a “Procure Goods” Action;

FIG. 10 is a diagram illustrating a “Procure Goods” Collaboration;

FIG. 11 is a diagram showing a Predicate Justification snapshot;

FIG. 12 is a diagram showing a Justification snapshot;

FIG. 13 is a diagram showing a Verbal Justification snapshot;

FIG. 14 is a diagram showing Justification generally in the meta model;

FIG. 15 is a class diagram of a meta model in accordance with anotherembodiment of the invention;

FIGS. 16 to 18 are more detailed views of the mea model of FIG. 15; and

FIG. 19 is a schematic diagram demonstrating the use of a qualifiedasset pool.

An embodiment of the invention is described in detail below withreference to FIGS. 1 to 14.

In at least the preferred embodiments, the invention provides a softwaredevelopment process which allows iteration, but does so in awell-controlled manner.

A use case may, for example, be “Purchase Goods” in a shopping portal.Although a use case may be nothing more than a textual description offunctionality, when used correctly it is a very effective tool for“fencing in” the project scope and allows for excellent segmentation ofdeliverables within the project plan. Also, use cases define a set ofrequirements for a project, allowing a project manager to implementchange control in a well-defined and transparent way. Thus if a customerdecides to change direction during a project then there is a verifiable“audit trail” of easily understood use cases that allow the changes tobe quantified for planning purposes.

A problem with the known Rational RUP approach is that iterations aredifficult to control in many projects. In some embodiments of thepresent invention, this is overcome by defining work-flows whichcollectively describe the project life-cycle. Each workflow correspondsto a set of activities, the outputs (artefacts) of which are verifiableand facilitate a clear progression within the project life-cycle. At theend of a work-flow all outputs are clearly defined and verifiable. Eachworkflow has a predecessor and a successor, with the exception of thefirst and the last.

Each iteration corresponds to a set of completed functional groups, afunctional group comprising one or more related use cases. Iterationsare controlled and may be run in parallel, sequentially, or a hybrid ofboth depending on the inter-dependencies between functional groupsthemselves and between the functional groups and shared packages. Theproject manager and senior technical people decide on the dependencies.

A preferred embodiment of the invention also provides an assetrepository, in which an asset is a reusable artefact developed duringthe project life-cycle. The asset repository comprises a meta model andcontent. Content is knowledge related to the delivery of systems and isembodied in reusable artefacts. The meta model is a schema for storageof the content.

The problem of demonstrating that certain software components actuallydeliver on their requirements is referred to as “traceability”. Forexample, the following are two use cases; “Procure Goods”, a highlyabstract representation of a procurement process, and “Order Goods”, arepresentation of one of the sub-actions of the Procure Goods use case.

Use Case 1, Procure Goods Characteristic Information To procure goodsusing one Description/Goal of use of several procurement case:techniques Primary Actor: Buyer Precondition: None Success EndCondition: Buyer owns procured goods and has paid for them.Main Success Scenario

-   -   1. The buyer orders goods from a supplier.    -   2. The buyer pays the supplier for the goods.    -   3. The supplier fulfils the order.    -   4. The use case ends.

Use Case 2: Order Goods (expansion of step 1 in the main successscenario of use case 1) Characteristic Information Description/Goal ofuse To formally request goods case: from a supplier Primary Actor: BuyerPrecondition: None Success End Condition: An order for the buyer'srequired goods is placed with a supplier.Main Success Scenario

-   -   1. The buyer requests the goods by submitting a purchase request        to the purchasing department.    -   2. The purchasing department approves the request.    -   3. The purchasing department creates a purchase order and sends        it to the supplier.    -   4. The use case ends.

Traceability is achieved by a mechanism known as “Refinement”.Refinement is the linking of two views of a business process, where oneview is a more detailed representation of the other. Noting thatprogressing through the stages of a software life-cycle essentiallyboils down to adding detail, it becomes clear that refinement is themeans by which the project manager can trace from requirements to code.The diagram of FIG. 1 shows how the two use cases can be representedusing an object diagram. Use case 1 is represented by the Collaboration“Procure Goods”. It contains three Actions (steps)—“Order Goods”,“Fulfill Order” and “Make Payment”. These actions (steps) represent thesteps in the “Main Success Scenario” of the use case. All Actions(steps) have an “Effect” that states its precondition and post-condition(but only the Effect for “Order Goods” is shown in the diagram). Thesecond use case “Order Goods”, is represented by the Collaboration (usecase) of the same name. It too contains three actions (steps) thatrepresent the steps of the main success scenario.

The traceability link is modelled using the refinement relationship. Itlinks an Action (step) to a Collaboration (use case), with the meaningthat the Collaboration (use case) is a more detailed representation ofthe Action (step). Applying this relationship repeatedly allows one tonavigate any depth of abstraction, including from business processmodels to software code. This mechanism is generalised in therepresentative implementation illustrated in FIG. 2, illustrating thesection of the meta model which enables refinement. The Collaboration(use case) is a, representation of a business process at some level ofabstraction. It has a single Effect, which is an optional Pre-conditionand a required Post-condition. The Effect defines the changes thebusiness process has on business entities. A Collaboration (use case)consists of a number of actions (steps) that represent the steps in thebusiness process. Each Action (steps also has an Effect that describeswhat changes it causes in business entities. It is important to notetherefore that Actions (steps) and Collaborations (use cases) are verysimilar—they both define changes in business entities. The onlydifference is that Collaborations (use cases) describe the stepsinvolved in the changes and Actions (steps) do not. This allows one tosay that Actions (steps) are abstract representations of Collaborations(use cases) (or alternatively Collaborations (use cases) are Actions(steps) that “expose their innards”). Now, if Actions (steps) areabstract representations of Collaborations (use cases), it is arelatively simple step to formally represent this relationship. This isachieved via the Refinement type. It links an Action (step) (via theActionRef type) and a Collaboration (use case) and has the semantic thatthe Collaboration (use case) is a more detailed view of the Action(step). The Refinement type has an attribute called “type”, which stateswhat stage of the project life-cycle that the associated Collaboration(use case) is at (business analysis, system analysis, or design forexample).

So, an Action (step) and a Collaboration (use case) can be associatedvia Refinement, and the semantic of the association is that theCollaboration (use case) is a more detailed view of the Action (step).In other words, the Collaboration (use case) has exactly the same Effectas the Action (step), but is modelled at a greater level of detail. Thisis what enables the traceability from business to code. Every refiningCollaboration (use case) has to be a plug-in replacement for itsabstract Action (step). This requirement is so important in fact that itneeds to be enforced. This is achieved by the Justification type,described below. In summary, traceability is applied via refinement inthe following ways:

Manage detail during Business Analysis—a refinement object of type“business” linking an Action (step) and a Collaboration (use case)states that the Collaboration (use case) is a more detailed view of theAction (step) but that both Action (step) and Collaboration (use case)express Business Analysis level detail.

Bridge Business Analysis and Systems Analysis—a refinement object oftype “system” linking an Action (step) at Business Analysis level to aCollaboration (use case) states that the Collaboration (use case) is aSystem Analysis level representation of the Action (step).

Manage detail during System Analysis—a refinement object of type“system” linking an Action (step) at System Analysis level and aCollaboration (use case) states that the Collaboration (use case) is amore detailed view of the Action (step) but that both Action (step) andCollaboration (use case) express System Analysis level detail.

Bridge System Analysis and Design—a refinement object of type “design”linking an Action (step) at System Analysis level to a Collaboration(use case) states that the Collaboration (use case) is a Design levelrepresentation of the Action (step). Refinement is also used to traceinto code, but that is treated as a separate pattern.

Reuse

This section presents the pattern that deals with the software problemof reuse. A number of reuse goals, as described below, are realised:

-   1. Reuse across the software life-cycle.-   2. Intra-model reuse.-   3. “Proactive” reuse.    Each type of reuse is dealt with below.    Reuse Across the Software Life-Cycle

To take the example of a customer that is looking for a procurementsite. The developers have completed a project that has a requirement incommon with this new one. The common requirement is “Procure Goods”.Additionally the customer has a requirement for a business processcalled “Special Procurement” and other functionality called “CustomerSpecific”. Re-use applies to the earlier life-cycle stages as well as itdoes to construction. Every Internet site requires authentication andsession management. Every B2C site requires Catalog Management, even ifnot obviously. Every B2B site, using the strict definition of B2B,requires exchange of business documents between businesses. Reuse alsoapplies to the requirements stage of the life-cycle, to systemrequirements, software and network architecture and navigationmechanisms—the entire software life-cycle infact.

In accordance with at least preferred embodiments of the invention, thegoal of a life-cycle is regarded as a process by which businessrequirements are continuously and traceably refined to a moresoftware-like form until they actually are software. This interpretationallows one to combine the notions of process and reusable assets in avery interesting and powerful way; any given reusable asset can be amore software-like representation of another reusable asset and as suchrepresents a step along the software life cycle. This means thatreusable assets linked in this way form a map that begins at businessrequirements and ends in code. Enabling reuse across the life-cyclemakes use of two mechanisms; refinement to provide traceability throughthe life cycle (as described above) and the asset repository. The assetrepository is a repository of reusable content that spans the softwarelife cycle. It includes business models that are refined into systemmodels that are refined into design models that are refined intosoftware components. Every element in the asset repository is made asgeneric as possible so it can be included in many customer-specificmodels.

A user can nominate elements from the asset repository for inclusion inhis project. He can also extend the content he has included from theasset repository. This mechanism is known as the “Include and ExtendPattern”. The diagram of FIG. 3 helps to illustrate. At the top of thisdiagram is an asset that contains a single Collaboration (use case)Package “Procurement”. That package contains two collaborations (usecases): “Procure Goods” and “Make Payment”. “Procure Goods” is thereusable Collaboration (use case) mentioned in the example above. Thereis a model towards the bottom of the diagram. A model represents aproject for a particular customer. This particular model needs toreference the reusable “Procure Goods” Collaboration (use case) in theAsset repository 100. It does so by first of all including a referenceto the package that contains the reusable collaboration (use case). Thisis achieved by the CollaborationPackageRef called “refl” which points tothe required Collaboration (use case) Package in the asset repository100. “ref1” contains a ModelCollaborationRef called “mrefl” that refersto the required reusable Collaboration (use case) in the Assetrepository 100. This has included the reusable Asset repository contentin the Model. The content can be extended since it is referred toindirectly by the ModelCollaborationRef instance. This instance can haveother instances and content associated with it. In this case it has aPhaseInstance instance associated with it. Additionally, the“Procurement” package included in the Model from the Asset repository100 can be extended, since it is included by reference. In this example,the referring object, “refl”, has a second Collaboration (use case)added to it—“Special Procurement”. This addition is made withoutaffecting the content in the asset repository 100. In a sense, thiscontent is “layered” over the asset repository 100 content. As a furtherillustration of the independence of the Model from the asset repository100, the Model has a second CollaborationPackage, “Customer Specific”that is purely local to it. It can be shown that the refinementmechanism described above applies to content included from the assetrepository 100. This allows model builders to include a Collaboration(use case) from the Asset repository and make it more specific viaRefinement. For example, the model builder might include a Collaboration(use case) called “Make Payment” that includes an Action (step) called“Transfer Funds”. The model builder can add a refinement to the“Transfer Funds” Action (step) to support customer specific transferfunds mechanisms—“Transfer Funds by EFT” for example.

The diagram of FIG. 4 shows the section of the meta model that enablesthe “Include and Extend Pattern”. The include and extend pattern is bestexplained-by looking at the mechanism of inclusion and extensionseparately. Any content that has to be included in a model from an assetrepository 100 is represented by two types. One is the content itself,the other is a reference to the content (in terms of FIG. 4, the contentis represented by the type called “CollaborationPackage”, which is apackage of pure use cases and the reference type is“CollaborationPackageRef”, which is a reference to such a package andcontains the context attributes).

References inherit from real types—they are the real types and more. The“more” bit is that they may refer to a real type and delegate toit whilestill retaining the ability to act exactly like the real type. Forexample, a CollaborationPackageRef will refer to a singleCollaborationPackage (use case package). However, it can also containCollaborations (use cases), as if it was the real type itself.

Real content is always navigated to via the reference types. Thisenables one to ignore where real content is located—the real contentmight share the same parent as the reference type, or it might be insome totally different parent. So inclusion is supported. The onlyquestion left to be answered is where to locate the real content. Therule here is to always locate it where it is first created. For example,the real collaboration (use case) “Procure Goods” is located in the“Procurement” package in the Asset repository. This is because the Assetrepository editor first created the collaboration (use case) in thecontent of that package. Additionally, the CollaborationPackage“Customer Specific” is located in the Model, because this is where theModel builder first created it. Therefore, inclusion is supported usingthe pattern shown in FIG. 5. In this diagram, the types that representreal content are known as “Real” and the types that refer to content,and contain contexts attributes, are known as “Reference”.

Extension builds on the Include pattern by introducing special cases ofreference types. In terms of the diagram of FIG. 4,ModelCollaborationRef is a special case of a reference type. It inheritsfrom a Reference type and defines new behaviour to achieve extension. Inthis case it adds a PhaseInstance object. So this is the rule forextension of included content: create a type that inherits from therelevant Reference type and define the extending behaviour. Suchextending types are known as “ExtendingReferences”. So, extension issupported using the pattern illustrated in FIG. 6:

The Include and Extend Pattern in the meta model is used for thefollowing applications:

-   -   Inclusion of Collaboration (use case) Packages in Models    -   Inclusion of Collaborations (use cases) in Models    -   Inclusion of Actions (steps) in Models    -   Inclusion of Actors and Types in Models    -   Extension of included Collaboration (use case) Packages (by        addition of Collaborations (use cases))    -   Refinement of included Collaborations (use cases)    -   Sharing of Types and Actors—in the asset repository 100, in        models and between the asset repository 100 and models.        Intra-Model Reuse

A business model uses business processes and entities in numerouscontexts. For example, the business process “Make Payment” may be usedin a business model to pay for received goods, issue a refund or award aprize. Regardless of the business context that the process is used in,its effect is still the same: money passes from payer to payee. So, theproblem is how to realise this reuse opportunity.

The meta model realises this reuse opportunity by separating the effectof a business process and its business context. The effect is modelledusing an Action (step), which captures the business entities and whathappens to them during the business process. The business context ismodelled using a Business Description, which captures what the processmeans to the business. To enable inclusion of an Action (step) in manyCollaborations (use cases), Actions (steps) are always navigated to viaActionRef objects. An ActionRef may refer to an Action (step) that iscontained by its parent Collaboration (use case) or it may refer to anAction (step) that is contained in some other Collaboration (use case).The question then is where to locate Actions (steps). The rule is thatActions (steps) are always placed in the Collaboration (use case) inwhich they are created and referred to via an ActionRef. This mechanismis called the include and extend Pattern and is applied through the metamodel to allow intra-model reuse of Actions (steps), as described here,and also Types and Actors. The diagram of FIG. 7 shows the section ofthe meta model that enables intra-model reuse. The Collaboration (usecase) is a business process that has a purpose in a given business. Thispurpose is represented using a BusinessDesc object. The Collaboration(use case) describes the steps involved in the business process itrepresents by referring, via ActionRef objects, to any number of Action(step) objects that describes a discrete change of state in a number ofbusiness entities. The sum of these changes of state realise theCollaboration (use case) change of state (Effect). However, everyActionRef adds a business reason for the Action (step) that it refersto. This business reason is independent of Action (step), therebyenabling reuse of Actions (steps) in many business contexts. The diagramof FIG. 8 illustrates. FIG. 8 shows one Collaboration (se case) “ProcureGoods” that contains an Action (step) called “Make Payment”. That Action(step) is used for the business reason for paying a supplier for goodsreceived. There is a second Collaboration (use case) “Make Refund” thatalso uses the “Make Payment” action (step) in the first Collaboration(use case). But this second Collaboration (use case) uses it for thedifferent business reason to refund a customer for substandard services.

Thus the embodiment described hereinabove provides for Sharing ofActions (steps)—in the asset repository 100, in models and between theasset repository 100 and models.

Proactive Reuse

The typical approach to acquiring reusable assets is to retrospectivelyharvest them from completed projects. There is a problem with thisapproach in that it is applicable only on projects that are quitesimilar to previous projects. This makes it difficult to move into a newbusiness area and retain the benefits of a reuse strategy. The abilityto quickly move into new business areas is critical for any softwareorganisation, especially those involved in the dynamic business ofe-business solution provision.

The present embodiment provides a division, called the Content Group,that proactively creates reusable artifacts for given businesses anddisseminates them through the asset repository 100. The Content Groupcan be instructed to create assets in selected businesses. The groupwill actively pursue that task while the sales force is winningbusiness. The Content Group will create new assets and may re-factorexisting assets to make them more suitable for the given businessdomain. When a contract is won and a project becomes live, project teammembers can leverage the assets that the Content Group has alreadygenerated.

Thus the embodiment described hereinabove provides for proactivereuse—proactively generating high quality models for business domainsthat are strategic.

Technology Mapping

Once the customer has signed off requirements, technology must beselected to realise them. Some of this technology will be off-the-shelfsoftware; and some of it will be customised development. The problem ischoosing the right technology for the customer's requirements.

An important thing to note about the meta model is that it uses auniform modelling methodology from business to code. Business processesare represented as changes in the state of business entities via theirEffect object. The same mechanism is used to capture business processesthat are modelled at the system level. And the same process can be usedto model software components. A software component has an effect in thesame way as the highly abstract process has, except that the formerspeaks in terms of software entities. This enables one to leverage therefinement mechanism to map requirements to software components. Thecomponents can be Sun™, Microsoft™ or any other component type.Alternatively they can be notional components that capture the effect ofnon-componentised software entity. What this means is that once acustomer has selected their requirements, one can look at thetechnologies that implement their requirements and make recommendationsaccordingly. In other words, the system advises on what technologies oneneeds to implement the system.

Thus the embodiment described hereinabove achieves Technology Mapping—byleveraging the mechanism of refinement, business requirements can beassociated with the technologies that implement them.

Justification

The refinement mechanism realises traceability, as described above. Itenables association of an Action (step) and a Collaboration (use case)with the semantic that the Collaboration (use case) is a more detailedrepresentation of the Action (step), and as such represents a step alongthe software life-cycle. But how does one prove that this statement iscorrect? Therefore, it is important to apply rigor to the refinementrelationship such that the refining Collaboration (use case) isdemonstrably equivalent to the abstract Action (step).

The present embodiment addresses this problem as described withreference to FIG. 9. In this situation, there are no pre-conditions. Thepost-condition is that the buyer owns the Goods and the Supplier hasbeen paid for them. This is equivalent to a more detailed Collaboration(use case) illustrated in FIG. 10. In this situation, there are nopre-conditions and the post-condition is that the Buying Company ownsthe Goods and the Supplying Company has been paid for them. The solutionto this problem is enabled by the introduction of the mechanism ofJustification. Every refinement has an associated Justification thatstates how the abstract Action (step) is realised by the refiningCollaboration (use case). There are three types of justification.

-   1. The first, Predicate Justification, is the most rigorous as it    can be made subject to machine validation. It states how each clause    in the Action's (step's) precondition expression is realized by a    clause (or a set of clauses) in the Collaboration (use case)    precondition. The same applies for the post-condition.-   2. Diagrammatic Justification contains UML relationships that show    how entities involved in the abstract Action (step) are realised in    the refining Collaboration (use case).-   3. Verbal Justification is the least rigorous justification    mechanism as it consists purely of an explanation in English (or    whatever language) how the abstract entities are realized in the    refinement.

Each justification type is illustrated by snapshot diagrams, andreferring to FIG. 11 a Predicate Justification diagram is shown.Predicates based on Object Constraint Language (OCL) can be justifiedusing Predicate Justifications. Assume there is an Action (step) whosepost-condition is “buyer inventory +=goods” and there is a refinement ofthat Action (step) that has the post-condition“goodsReceiver.employer.inventory +=goods”. The snapshot diagram forthis case is illustrated in FIG. 11. In this diagram, the PredicateJustification links two predicates and explains verbally how they areequivalent. Assume there is an Action (step) that involves an Actorcalled “buyer” and that this Action (step) is refined by a Collaboration(use case) that replaces the notion of “buyer” with an Actor called“goodsReceiver” and a type called “Company” and the goodsReceiver isemployed by the Company. The snapshot diagram for this case is presentedin FIG. 12. This snapshot states that the Actor called “buyer” is thesame as an Actor called “goodsReceiver” that is employed by a company.This is achieved through the Diagrammatic Justificationinstance—bottomcentre. It has three associations. The leftmost onestates that the “buyer” Actor has an aggregate relationship with the“goodsReceiver” Actor. This means that the “buyer” consists of the“goodsReceiver”. The middle association states that the “buyer” Actorhas an aggregate relationship with the Company instance. The rightmostassociation states that there is a relationship between the“goodsReceiver” Actor and the Company and that this association is knownas “employment”.

A Verbal Justification is a series of paragraphs of text that explain inEnglish how the entities in the abstract Action (step) involved in arefinement are realised in the refining Collaboration (use case). Thesnapshot diagram of FIG. 13 illustrates this, and the diagram of FIG. 14shows the section of the meta model that enables justification. AJustification consists of any number of DiagrammaticJustifications,VerbalJustifications and PredicateJustifications.

Thus, the embodiment described hereinabove applies rigor totraceability—by requiring that refinements; are justified, thejustification processes forces the developer to think about and makeexplicit the relationships between abstract Actions (steps) and therefining Collaborations (use cases). Additionally, the presence of thisinformation guides the reader through the levels of abstraction andmakes traceability explicit.

A further embodiment is described with reference to FIGS. 15 to 19. Asin the foregoing description, the term “Collaboration” may be taken tobe interchangeable with the term “use case”. Furthermore the term“Action” may be taken to be interchangeable with the term “step” or“task step”. No inference is to be drawn by use of the latter termrather than the former.

Any features not described in relation to FIGS. 15 to 19 should be takento be the same as the corresponding features described with reference toFIGS. 1 to 14.

FIG. 15 shows the meta model 2 of a further embodiment of the inventionin the form of a mete model class diagram. The meta model 2 is theschema by which the content of the model is structured. The variousparts thereof are described with reference to FIGS. 16 to 18 from whichthey may be seen more clearly and thus are not described with referenceto FIG. 15.

The relationship between a project 4 and use cases 6 is shown in FIG.16. The project 4 contains all the components that model a realsystem—i.e. it represents software which has been developed or is beingdeveloped in accordance with a method and tool embodying the invention.

The use cases 6 are an arrangement of related steps to achieve somebusiness goal. Use case packages 8 are the named containers of use cases6. They may in turn contain other use case packages 8. Use case packages8 allow for the logical or conceptual grouping of associated use cases.

The root node of the meta model is a qualified asset pool (QAP) 10. TheQAP 10 comprises use case packages 8, which in turn contain use cases 6,which have been modified or purified and approved by an asset purifierteam.

Use case pointers 12 are pointers to real use cases 6, which may becreated in the current project 4 or a ‘read only’ link to a reusable usecase in another project. Similarly, use case package pointers 14 arepointers to real use cases packages 8, which may be created in thecurrent project 4 or a ‘read only’ link to a reusable use case packagein another project.

The project 4 has a collection 16 of goal levels 18. The goal levels 18are a process specific representation of what >level=a use case 6 can bedemoted as. By default the described embodiment specifies five such goallevels: “very high summary”; “summary”; “user goal”; “sub-function”; and“too low”.

A list 20 of actors, i.e. entities with which the project 4 mayinteract, is stored with the project. Also stored with the project 4 arefreeform notes 22, a list 24 of links between the project and externalsystems, a glossary 26 of the terms used in the project and a list 28 ofnon-functional requirements. These are requirements that must be met bythe project as a whole but which do not translate into functionality.Examples of non-functional requirements are “we must be able to processa hundred transactions a second”, or “the user interface must beusable”. Although not shown in FIG. 16, non-functional requirements mayalso be associated with individual use cases.

Further details of the meta model 2 may be seen in FIG. 17. It will beseen that each use case 6 has one main success scenario 30 and may alsohave one or more alternative scenarios 32. Additionally a use case 6 Mayhave one or more exceptions 34. An exception(s) 34 handle(s) the case(s)in which the effect of the associated Step will not happen. An exception34 has a single pre-condition object that states the condition underwhich the exception 34 will execute. The exception 34 will also have anassociated use case that shows how to deal with the exceptionalcondition.

A scenario 30, 32, 34 (represented collectively by the scenario object36) has, in general one or more steps 38 within the scenario 36. Thesteps are linked to use case 6 by means of a refinement 40. This is thenature of the recursive structure in accordance with the invention: astep 38 may be refined by a refinement 40 to give a use case 6, a moredetailed but equivalent description of the step 38; the use case hasscenarios 36; scenarios contain, in general, a number of steps 38; eachof these steps 38 may themselves be refined to a yet more detailed usecase 6 etc.

Each refinement 40 has a justification 42. The justification 42demonstrates how the resultant effect of a use case 6 (or moreaccurately the main success scenario 30 thereof) is equivalent to thatof the parent step 38. The justification 42 thus provides traceabilitybetween the abstract step 38 and the use case 6 that is a more concreterepresentation of it. The justification may be formal or informal andmay have an optional verification 44. Verification 44 proves that theresultant-effect of the abstract and refined views are the same.Verification 44 could be casual, rigorous, mathematical etc.

An asset 46 is a piece of work in a business context which is capable offulfilling the resultant effect of a step 38 exactly. Typically assets46 are only associated with detailed refined use cases 6. Assets can besoft 46 a, e.g. documents, html pages etc., or hard 46 b, e.g. computercode.

As described above, actors 48 are entities that participate in one ormore steps 38. Finally, a business description 50, that is a textualexplanation of a business action being carried out by a use case 6, maybe recorded.

FIG. 18 describes the role of pre- and post-conditions. A pre-condition52 defines the situation in which a step 38 (FIG. 17) can start—i.e. itmust be true before the step may take place. A post-condition 54 must betrue when the step has been performed i.e. it must equal the resultanteffect of the further steps of the main success scenario of the use casewhich is a refinement of the step.

The predicate object 54 fully supports predicate logic usage byimplementing Object Constraint Language (OCL) which is part of theUnified Modelling Language specification of the Object Management Group;Sets and Predicate basics. This forms the basis for OCL used in pre andpost-conditions.

The Set interface 58 defines the mathematical Set logic. The Predicateinterface 60 defines the mathematical predicate logic. The OCL interface62 defines the OCL exactly as specified in the Unified ModellingLanguage specification of the Object Management Group.

Finally FIG. 19 is a schematic view of the asset repository. Thisdiagram demonstrates that the software development tool comprises anasset repository 64 which includes a separate Qualified Asset Pool (QAP)66. The asset repository 64 in general contains unqualified assets 68,whilst the QAP 66 contains qualified assets 70. These are assets whichhave been ‘purified’ by removing any context or project specificinformation to allow their reuse across other projects.

It will be appreciated by those skilled in the art that whilst certainpreferred embodiments of the present invention have ben described, manymodifications and variations may be made within the scope of the presentinvention.

1. A method of developing software capable of performing a task, said task comprising at least one task step required to perform said task, the task step having a resultant effect, wherein the method comprises: recording a use case comprising one or more scenarios, the or each scenario comprising one or more further steps; recording said scenario or one of said scenarios as a main success scenario such that the resultant effect of said main success scenario is the same as the resultant effect of said task step. 2.-63. (canceled) 